This invention relates to system dependability testing and, more particularly, to such testing via fault injection.
Fault injection arrangements and techniques are known in the art. For the most part, prior known fault injection arrangements have limited flexibility regarding accommodation of hardware and software platforms, programs, and fault injection techniques. Indeed, fault injection is a necessity when testing the robustness of a system to unintended or unexpected events, because such events are often extremely difficult to produce through use of traditional testing techniques. See for example, an article by N. P. Kropp, P. J. Koopman and D. P. Siewiorek entitled xe2x80x9cAutomated robustness testing of off-the-shelf software componentsxe2x80x9d, Proceedings 28th International Symposium on Fault-Tolerant Computing, (FTCS-28), pages 231-239, Munich Germany, June 1998, for one such prior fault injection tool. Notwithstanding, a significant obstacle to the task of systematic testing of system dependability is still the lack of flexible, easy-to-use fault injection tools.
The problems and limitations of prior fault injection tools are overcome in a unique fault injection tool based on an object-oriented architecture in which identical or similar functionality is abstracted out into so-called base classes, and is implemented in an object-oriented program language. This results in a fault injection tool having greater flexibility, ease and portability in realizing the basic functionality of the fault injection process including fault injection, workload generation and data collection.
Specifically, the basic functionality of the fault injection process is abstracted into three base classes, namely, a fault injector, a workload generator and a data collector. A control class performs configuration and management of the objects that are instantiated from the base classes. The control class also implements a graphical user interface. For each base class there is a corresponding core class that performs control and management of a so-called associated xe2x80x9cpluginxe2x80x9d. Each of the core classes can be implemented as a single class or as a pair of distributed classes. For example, the fault injector (FI) core class can be implemented as a single FI core class or as a FI/FIRemote pair. Similarly, the workload generator (WG) core class can be implemented as a single WG core class or as a WG/WGRemote pair. Likewise, the data collector (DC) core class can be implemented as a single DC core class or as a DC/DCRemote pair. If a core class is implemented as a pair, the FI, WG or DC object controls operation of the FIRemote, WGRemote or DCRemote object, respectively. For each core class, the associated plugin performs the actual functionality. A plugin is a dynamically loaded object that can be linked with the object instantiated from the core class without recompilation of the core class. Each plugin includes al least a corresponding base class and, possibly, hierarchical derived custom classes from the base class. The hierarchical derived custom classes facilitate software reuse and facilitate the creation of plugins. Many actions performed by the plugins are identical or similar for a wide range of fault injection, workload and data collection processes. These identical and similar actions are implemented in the abstract base classes. Intermediate classes can be derived from the base classes, and additional intermediate classes or the final end classes are derived from these intermediate classes.